Fix/token permissions id 20260911 - #93

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Closing this PR unlanded, as part of a decision on the whole fix/token-permissions-id-20260911 family (21 PRs). Not a rejection of least-privilege permissions — a decision to fix the generator instead of 21 branches.

Why the family is not landable

The sweep narrows contents: write to contents: read at the workflow level on workflows that genuinely write — git push, gh pr merge --auto, gh release create, create-pull-request. Where the writing job has no permissions: block of its own and authenticates with GITHUB_TOKEN, the narrowing silently removes a permission the workflow needs.

It is silent in the worst way. The diff is valid YAML and fails no check, so the PR shows green; the damage fires on the next write, which may be weeks later and in a different workflow than the one reviewed. Where the push is written git push … || echo "::warning::", a denied push emits a warning rather than a failure and the run stays green forever.

In several files the sweep rewrote the value and left the justifying comment attached to it, so the patch states its own requirement and then removes it:

 permissions:
-  contents: write # needed to enable auto-merge
+  contents: read # needed to enable auto-merge

Root cause — in the rule, not in these branches

hypatia's workflow_audit.ex:463 tests:

Regex.match?(~r/^permissions:/m, content)

anchored at column 0. A job-level permissions: block is indented, so the rule structurally cannot see it. It can therefore only ever rewrite workflow-level permissions, and cannot tell a workflow that needs the write from one that does not. The rule runs across the estate, which is why this arrived as a 21-PR family rather than one bad patch.

The estate already gets this right in three places (standards/signed-push-smoke.yml, KnotTheory.jl/release.yml, gitbot-fleet/inbox-steward.yml), all using per-job elevation — so this is generator inconsistency, not policy.

What happens instead

• The narrowing is not reverted. Least privilege at the workflow level is correct and is kept.
• The family will be regenerated once the anchored regex is fixed, with the write scope elevated per job on the jobs that actually write. When a job-level block is added it must restate every scope the job was inheriting, because a job-level permissions: block replaces the workflow-level block rather than merging with it.
• Two default branches already broken by the landed sweep are repaired directly, under a narrower ruling: fix(ci): restore the write scope Dependabot auto-merge needs, per job rsr-template-repo#91 (the scaffolding template, so the defect propagates) and fix(ci): restore the write scope the release job needs, per job smtp-notify-action#17 (fails only after an immutable tag is published, leaving a tag with no release).

Nothing here is lost: the intended permissions hardening is deferred to a correct generator, not abandoned.

🤖 Generated with Claude Code

https://claude.ai/code/session_014QN8x5x4kNKY8EYCFsCmWB